System for bandwidth allocation in a computer network

ABSTRACT

A system for classifying, monitoring, controlling and otherwise managing and allocating bandwidth of a network to data streams. A method for allocating bandwidth of a data network to a plurality of data streams is provided. The method comprises specifying apportionment of the bandwidth to a plurality of data classes. Receiving a plurality of data streams wherein each data stream has an associated data class. Negotiating a transfer rate for each data stream, wherein the transfer rate is limited to the bandwidth apportioned to the data class associated with each data stream and transmitting the data streams on the data network at the negotiated transfer rates.

CROSS REFERENCES TO RELATED APPLICATIONS

This application claims priority from a co-pending provisional patentapplication filed on Jun. 1, 1999 as Ser. No. 60/137,160. Thisapplication is related to U.S. patent application entitled “PERFORMINGMULTICAST COMMUNICATION IN COMPUTER NETWORKS BY USING OVERLAY ROUTINGfiled Jun. 1, 1999 Ser. No. 09/323,869 and to U.S. ProvisionalApplication “SYSTEM FOR MULTIPOINT INFRASTRUCTURE TRANSPORT IN ACOMPUTER NETWORK” filed Jun. 1, 1999 as Ser. No. 60/137,153. Each ofthese applications are hereby incorporated by reference as if set forthin full in this document.

FIELD OF THE INVENTION

This invention relates generally to the operation of a data network, andmore particularly, to the allocation of bandwidth of a data network to aplurality of data streams.

BACKGROUND OF THE INVENTION

Networks need to efficiently use their bandwidth, especially whenbroadcasting high-bandwidth information. Broadcast information istypically characterized by a relatively small number of data sourcestransmitting data to a large number of destinations, such as end-usersor clients. For example, the audio signal from an FM radio station maybe digitized and broadcast over a public data network, like theInternet, thereby allowing a large number of end-users around the worldto receive the digital broadcast.

A subset of broadcasting, known as multicasting, occurs when a broadcastis intended to be received by a selected set of clients. Unfortunately,current approaches have failed to achieve efficient multicasting overlarge data networks. Part of the reason for this failure is the lack ofa scalable infrastructure to handle subscriptions, distribution andcontrol of the multicast information.

Likewise, when a large number of time-critical unicast connections aremultiplexed together over a network, for instance, to support voice overIP or on-demand streaming media, the network must efficiently deliverthese streams and retain the best possible delivered quality even whenthe offered load exceeds the bandwidth of the intervening network links.

FIG. 1 shows a network portion 100 of a typical data network. Thenetwork portion 100 comprises nodes 102, 104 and 106 coupled together bylinks 108 and 110. All the links of network portion 100 can beconsidered bidirectional links allowing both the transmission andreception of information. An information source 112 is coupled to node102 by link 114. Clients 116, 118 and 120 are coupled to node 106 bylinks 122, 124 and 126, respectively. Links 128, 129, 130, 132 and 134are coupled to other portions of the data network (not shown).

In a typical mode of operation, information source 112 forwardsinformation to node 102 for distribution throughout the data network.The information is in the form of data packets where a series of datapackets forms a data stream. For example, a data stream destined forclient 118 would travel from node 102 to node 104, then to node 106 andfinally to client 118. Each node receives the data packets of the datastream and forwards them in an output stream to the next node. In thismanner, data streams may be distributed around the network from a sourceto a destination using a number of different data paths.

Unfortunately, transmission problems can occur because of the way a nodeforms its output stream. One problem concerns the issue of bandwidthallocation, since each link has only a fixed amount of bandwidth. Incurrent networking schemes, if traffic backs up at a node, due tooutbound congestion, some of the incoming packets will be dropped, andas a result, the quality of the data streams will be degraded.

One situation where a bandwidth limitation is especially critical isduring the transmission of real-time data streams. Real-time datastreams comprise video, audio or other types of data streams where thequality received by the client will degrade if the stream isinterrupted. For example, if a real-time video stream transmitted toclient 118 loses data packets due to a bandwidth limitation of link 108,the quality of the data stream received by client 118 will be degraded.The client 118 will perceive the real-time video as having pauses, jumpsor skips accompanied by glitches in the sound portion. As a result,client 118 may not want to receive such a degraded video stream.

SUMMARY OF THE INVENTION

The present invention provides a system for classifying, monitoring,controlling and otherwise managing and allocating bandwidth to datastreams in a data network. The invention can be used in any networkenvironment including, but not limited to, unicast networks, broadcastnetworks or other network environments where efficient use of networkbandwidth is desired.

In one embodiment, a method for allocating bandwidth of a data networkto a plurality of data streams is provided. The method comprises:specifying apportionment of the bandwidth to a plurality of dataclasses; receiving a plurality of data streams wherein each data streamhas at least one attribute that associates the data stream with a dataclass; negotiating a transfer rate for each data stream, wherein thetransfer rate is limited to the bandwidth apportioned to the data classassociated with each data stream; and transmitting the data streams onthe data network at the negotiated transfer rates.

In another embodiment, apparatus is provided for allocating bandwidth ofa data network to a data stream wherein the data stream has streamannotations. The apparatus comprises a plug-in having logic to receivethe data stream and to determine a plurality of transfer rates. Theplug-in also has logic to transform the data stream into a transformedstream having a transfer rate selected from one of the plurality oftransfer rates. An allocator is coupled to the plug-in and has logic toreceive the data stream. The allocator has a policy tree that specifiesapportionment of the bandwidth to a plurality of data classes. Theallocator also has logic to associate the data stream with a data classbased on the stream annotations and to negotiate with the plug-in toselect the transfer rate from the plurality of transfer rates, whereinthe transfer rate is limited to the bandwidth allocated by the policytree to the data class. An output link is coupled to the plug-in and haslogic to transmit the transformed stream on the data network at thetransfer rate.

In another embodiment, a method of operating a data network to allocatebandwidth of the data network to a data stream is provided. The methodcomprises: annotating the data stream with stream annotationsrepresentative of a data class; establishing a policy tree thatspecifies apportionment of the bandwidth of the data network to aplurality of data classes; determining the data class of the data streambased on the stream annotations and negotiating a transfer rate for thedata stream limited to the bandwidth specified by the policy tree forthe data class; transforming the data stream to a transformed streamhaving the transfer rate; and transmitting the transformed stream on thedata network at the transfer rate.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a prior art network portion 100;

FIG. 2 shows a network configuration incorporating an embodiment of thepresent invention;

FIG. 3 shows a computer device 300 suitable to implement an embodimentof the present invention;

FIG. 4 shows the internal architecture of the computer device of FIG. 3;

FIG. 5 shows a block diagram of a media device 450 constructed inaccordance with the present invention;

FIG. 6A shows a detailed block diagram of a bandwidth allocation device500 constructed in accordance with the present invention;

FIG. 6B shows another embodiment of a detailed block diagram of thebandwidth allocation device 500 constructed in accordance with thepresent invention;

FIG. 7 shows an exemplary policy tree 600 for use with the presentinvention;

FIG. 8 show, a table 700 representative of control information for usewith the present invention;

FIG. 9 shows a portion of a policy tree allocating bandwidth to selecteddata streams using the stream annotations;

FIG. 10 shows a method 800 of operation of the device 500 of FIG. 5;

FIG. 11 shows a method 900 of operation of the device 500 of FIG. 5;

FIG. 12 shows a method 1000 of operation of the device 500 of FIG. 5;and

FIG. 13 shows a method 1100 of operation of the device 500 of FIG. 5.

DESCRIPTION OF THE SPECIFIC EMBODIMENTS

The present invention provides a system for classifying, monitoring,controlling and otherwise managing and allocating bandwidth to mediastreams in a data network. Transmission rates for the media streams areselected with respect to a fixed but administratively configurablepolicy, so that the available bandwidth of the data network can beefficiently utilized.

FIG. 2 shows the network portion 100 of FIG. 1 and further comprisesmedia devices 202, 204 and 206 coupled to nodes 102, 104 and 106, bylinks 208, 210 and 212 respectively. The media devices are used to forma virtual network such as an overlay network as described in the aboveidentified patent application having Ser. No. (09/323,869). The mediadevices function to forward data streams around the data network in away that maintains bandwidth allocations for the data streams. This isaccomplished by dedicating at least a portion of the available bandwidthof the data network to the virtual overlay network formed by the mediadevices. As a result, clients receive real-time data streams withoutinterruption and with excellent quality. A description of the formationof the virtual overlay network is beyond the scope of this invention,however specific details can be found in the above identified patentapplication having Ser. No. (09/323,869).

The media devices couple to their respective nodes to receive datastreams arriving from any other links coupled to the node. For example,media device 202 receives data streams from links 114, 128, 129 and 108.The links that couple the media devices to the nodes provide both inputand output transmission paths. After receiving the arriving datastreams, the media devices form output data streams for transmission onthe data network.

FIG. 3 shows a computer device 300 suitable for use as a media device inaccordance with the present invention. Computer device 300 includesdisplay 302 having display screen 304. Cabinet 306 houses standardcomputer components (not shown) such as a disk drive, CDROM drive,display adapter, network card, random access memory (RAM), centralprocessing unit (CPU), and other components, subsystems and devices.User input devices such as a mouse 308 having buttons 310, and akeyboard 312 are shown. Other user input devices such as a trackball,touch-screen, digitizing tablet, etc. can be used. In general, thecomputer device 300 is illustrative of one type of computer system, suchas a desktop computer, suitable for use with the present invention.Computers can be configured with many different hardware components andcan be made in many dimensions and styles (e.g., laptop, palmtop,server, workstation, mainframe). Any hardware platform suitable forperforming the processing described herein is suitable for use with thepresent invention. For example, although FIG. 2 shows media devices 202,204 and 206 coupled to nodes 102, 104 and 106, respectively, thefunctions and processing of the media devices may be incorporateddirectly into the nodes.

FIG. 4 illustrates subsystems that might typically be found in acomputer device such as computer device 300. Subsystems within box 400are directly interfaced to an internal bus 410. Such subsystemstypically are contained within the computer system, such as within thecabinet 306 of FIG. 3. Subsystems include input/output (I/O) controller412, System Random Access Memory (RAM) 414, Central Processing Unit(CPU) 416, Display Adapter 418, Serial. Port 420, Fixed Disk 422 andNetwork Interface Adapter 424. The use of the bus 410 allows each of thesubsystems to transfer data among the subsystems and, most importantly,with the CPU 416. External devices can communicate with the CPU or othersubsystems via the bus 410 by interfacing with a subsystem on the bus.Monitor 426 connects to the bus through Display Adapter 418. A relativepointing device (RPD) 428 such as a mouse connects through Serial Port420. Some devices such as keyboard 430 can communicate with the CPU 416by direct means without using the main data bus as, for example, via aninterrupt controller and associated registers (not shown).

As with the external physical configuration shown in FIG. 3, manysubsystem configurations are possible. FIG. 4 is illustrative of onesuitable configuration. Subsystems, components or devices other thanthose shown in FIG. 4 can be added. A suitable computer system can beachieved without using all of the subsystems shown in FIG. 4. Othersubsystems such as a CDROM drive, graphics accelerator, etc. can beincluded in the configuration without affecting the performance of thesystem of the present invention.

FIG. 5 shows a block diagram of a media device 450 that operates inaccordance with the present invention. The media device 450 is suitablefor use as one of the media devices 202, 204 or 206 in the data networkof FIG. 2. The device 450 has four inputs 1-4, a control input 452, andan output 454. One or more data streams arrive at the device 450 via thefour inputs 1-4. For purposes of convenience, it will be assumed thatonly one data stream arrives on each of the four inputs. However, thedevice 450 can be configured to have only one input at which multipledata streams arrive, alternatively, the device 450 can be configured tohave multiple inputs where one or more data stream arrive on each input.Each of the four data streams are routed to the output 454 fortransmission on the network. The output 454 has a transmission limitwhich represents the maximum transmission capacity available to thedevice 456 at the output 454. The transmission capacity may be limitedfor a variety of reasons. For example, the transmission capacity may bea physical capacity limitation or can result because the data networkhas restricted the output to this capacity limitation to regulatenetwork usage. Another way the transmission capacity of the output maybe limited can occur when a system administrator downloads instructionsvia the control input 452 to limit the output to a specific transmissioncapacity. As a result, the device 450 operates. to allocate theavailable output bandwidth to the input data streams in a way thatfollows administrative instructions and bandwidth limitations.

Each of the four input data streams can be transmitted on the datanetwork at one or more transmission rates. The selection of transmissionrates is done by the device 450 and depends on the type of data in thedata streams. For example, a data stream containing video images may betransmitted at one of several transmission rates wherein differences inthe quality of the video images result from the selection of thetransmission rate. A data stream containing programs or data files maybe transmitted at any number of transmission rates without degrading theinformation. The flexibility to transmit data streams at one of severalrates allows the device 450 to select transmission rates for the datastreams to achieve specific network goals, such as optimizingefficiency, implementing stream priorities or to accommodate specificadministrative requirements. For example, referring to therepresentative data streams of FIG. 5, input 1 can be transmitted at 20,10 or 5 megabits per second (20/10/5 m), while input 2 can betransmitted at 10, 5 or 2 megabits per second (10/5/2 m). Thus, duringoperation, the device 450 can select transmission rates for each of theinput data streams from the known available transmission rates, andthereby allocate the available network bandwidth at the output 454 tothe input data streams.

Accordingly, one method for the device to select a transmission rate foran input data stream uses bandwidth allocation parameters. The bandwidthallocation parameters are received when a system administrator, or someother system or external computer program, uses the control input 452 toinput the bandwidth allocation parameters into the device 450. Theallocation parameters define allocation of the available outputbandwidth to selected “data classes.” A data class defines one or more“types” of data streams. For example, a live video data stream is onetype of data stream and a data stream containing data files is anothertype of data stream. A data stream may also have sub-types. For example,a news broadcast and a weather broadcast are sub-types of live videodata streams. Thus, a data class can specify any combination of typesand/or sub-types of data streams. The device 450 first determines thetype of data stream, and thus the class, from control informationassociated with the data stream. The available transmission rates forforwarding the data stream are also determined. The device then selectsone of the available transmission rates for the data stream whichconforms to the bandwidth allocation for that particular class of datastream. For example, if input 1 carries a data stream of class “video”,while input 2 carries a data stream of class “audio”, a transmissionrate for each of the data streams is selected based on the allocationparameters. As a result, a transmission rate for input 1 is selected toconform to the bandwidth allocation for class “video” and a transmissionrate for input 2 is selected to conform to the bandwidth allocation forclass “audio.” Therefore, the allocation parameters can be used toallocate the available output bandwidth to specific types of incomingdata streams. As will be shown, a number of bandwidth allocation methodsand dynamic re-allocation methods are possible without deviating fromthe scope of the present invention.

In one method of operation, the device 450 allocates the outputbandwidth among all the input streams, so that all the input streamswill be forwarded on the network. For example, assuming that the outputcapacity limitation at the output 454 is 40 m and the four input datastreams have possible transmission rates at shown in FIG. 5, then in oneallocation scheme, the transmission rates may be selected so that input1 is 20 m, input 2 is 5 m, input 3 is 5 m and input 4 is 10 m. Thus, the40 m available at the output 454 would be fully utilized. In anotherallocation scheme, the control input may be used to input allocationparameters that allocate higher bandwidth to specific classes of datastreams. For example, if the types of data streams at input 2 and input4 are in the class allocated high bandwidth, a new allocation may resultwherein the transmission rates are selected so that input 1 is 5 m,input 2 is 10 m, input 3 is 5 m and input 4 is 20 m. Thus, the highestavailable transmission rates are selected for the data streams at inputs2 and 4 corresponding to 10 m and 20 m, respectively, while the datastreams at inputs 1 and 3 have transmission rates that divide theremaining 10 m of available output bandwidth. All manner of bandwidthallocations may be achieved by using the allocation parameters to selectthe appropriate transmission rates for the input data streams.Situations may even occur wherein one or more input streams are notforwarded on the network due to the settings of the allocationparameters. For example, based on one set of allocation parameters, thetransmission rates for inputs 1 and 4 may be selected to be 20 m each,thereby fully utilizing the available output bandwidth of 40 m. In thiscase, the data streams at inputs 2 and 3 would be lost, while the datastreams at inputs 1 and 4 would be forwarded at their highest availabletransmission rates.

FIG. 6A shows a detailed block diagram of a bandwidth allocation device500 constructed in accordance with the present invention. The device 500accepts a plurality of input data streams that comprise datarepresentative of a variety of subject matter content. For example, aninput data stream may comprise video data such as a movie or televisionbroadcast or real-time information such as news reports or weatherforecasts. A data stream may also comprise typical computer data such asprograms and/or data files. A first input data stream 502 and a secondinput data stream 504 are input to the device 500. The first input datastream 502 comprises only one data stream, for example, a data streamrepresenting a video broadcast. The second input data stream 504comprises a multiplexed data stream comprising up to N different datastreams. The data streams contain control information 506 whichdescribes different parameters of the data streams. For example, thecontrol information may have information about the origin or destinationof the data streams. The control information may also containinformation about the content of the data streams. For example, theauthor's name, type of broadcast or the duration of the broadcast. Thecontrol information 506 may form a part of the data stream, or thecontrol information may be transmitted in a separate control data streamthat arrives at the bandwidth allocation device 500 on one or moreinputs or via a separate control channel.

The allocation parameters represent a set of bandwidth policies 508 thatare provided to the device 500 from a system administrator or some otheradministrative source. The bandwidth policies are used to allocate thebandwidth of the data network available at output 510 of the device 500.The goal of the bandwidth policies is to achieve a desired allocation ofthe available output bandwidth among the classes of input data streams.For example, it may be desirable to give higher bandwidth to the firstdata stream 502, representing video data, so that transmission of thisstream will result in high quality video images when received. Thebandwidth policies 508 allow for dynamic allocation of the availableoutput bandwidth so that as different classes of input data streamsarrive or terminate, or as the requirements of an existing class of datastream changes, the bandwidth allocation can dynamically change.Utilizing the bandwidth policies 508, the device 500 can respond to avariety of changing network conditions to re-allocate the availableoutput bandwidth as required.

To process the incoming data streams, an allocator 512 receives thecontrol information 506 associated with the incoming data streams. Theallocator also receives the bandwidth policies 508 from the systemadministrator. Alternatively, the allocator may receive the bandwidthpolicies from an automated management system that operates either insideor outside the disclosed system. The bandwidth policies 508 are designedby to implement bandwidth preferences and, for example, can berepresented as a policy tree having a hierarchical structure. Anexemplary policy tree is discussed in detail with reference to FIG. 7.The bandwidth policies, which are not restricted to having a treestructure, may have any structure which relates bandwidth to arbitrarydata stream attributes, data stream types, or data stream classes. Thepolicy tree defines static policies that are used by the allocator 512to allocate the bandwidth of the data network based on the types of datastreams currently being received.

A plug-in manager 514 also receives the control information 506. Theplug-in manager 514 analyzes the received control information andactivates plugins to process the incoming data streams. A plug-in refersto software and/or hardware running on the media device and having thecapability of performing various processes on an incoming data streams.Each plug-in is created and specifically designed to receive the data ofa specific type of data stream. For example, a plug-in may be created tohandle layered video data or a plug-in may be created to handle nonreal-time computer data. In the embodiment of FIG. 6A, first and secondplug-ins 516, 518 and up to the N^(th) plug-in 520, are activated by theplug-in manager 514 to receive and process specific types of incomingdata streams.

Depending on the type of data stream and/or the attributes thataccompany the data stream, the plug-ins will determine one or moretransmission rates that can be used for forwarding the data stream onthe network. Once the available transmission rates are determined, theplug-ins negotiate with the allocator 512 to select one transmissionrate that can be used to forward their respective data stream on thenetwork. During the negotiation process, the plug-ins provideindications of the available rates for the data stream to the allocator.The allocator 512 responds to the plug-in by indicating which rateshould be used. The allocator 512 uses the control informationassociated with each stream in conjunction with the bandwidth policiesto select a negotiated transmission rate for each data stream. Thenegotiated transmission rate is selected from the available ratesdetermined by the plug-in. By adhering to the bandwidth policiesprovided by the system administrator, the allocator is able to maximizethe efficiency and utilization of the available network bandwidth bynegotiating preferred transmission rates for each type of data stream,while conforming to the available capacity limitations available at theoutput.

At the completion of the rate negotiation, the plug-ins transform thedata of the incoming data streams to the negotiated transmission rates,via transformers 526, 528, and 530, thereby forming transformed streamsas shown at 532, 534 and 536. To accomplish this, the plug-ins usetransformation processes to transform the input data streams, to thetransformed data streams having the negotiated transmission rates. Inone embodiment, the transformation process might simply select a subsetof the layers that comprise a multi-bitrate signal to form thetransformed data stream. In another embodiment, the transformationprocess might decode the signal and re-encode it with alternativecompression parameters to decrease the bit rate at the cost of lowersignal quality at the receiver. The transformed data streams are coupledto an output link 522 where the streams are combined to form an outputdata stream 510. The output data stream 510 comprises the input datastreams at the negotiated transmission rates. The transformed datastreams comprise streams of data packets being pushed out of theplugins. The output link 522 has logic to receive data packets from theplugins and also includes logic to combine the data packets into theoutput data stream 510. The output data stream 510 is forwarded to endusers or to other routing devices in the network. Other routing devicesin the network may be identical to the bandwidth allocation device 500wherein the same or another set of bandwidth policies apply. Thus, it ispossible that a data stream having a first negotiated transmission rateat one bandwidth allocation device may have a different negotiatedtransmission rate at other bandwidth allocation devices in the network.

FIG. 6B shows another embodiment of the bandwidth allocation device 500.In the embodiment of FIG. 6B, each of the plugins has an output queue asshown at 550, 552 and 554. The output link 522 is replaced with a packetscheduler 556. The scheduler 556 polls the output queues to pull datapackets out of the plugins and thereby form the output stream 510.Regardless of whether the bandwidth allocation device 500 uses theoutput link 522 or the packet scheduler 556, the output data stream 510contains the input data streams having transmission rates derived fromthe bandwidth allocations defined by the bandwidth policies of thepolicy tree.

FIG. 7 shows an exemplary policy tree 600 for use in the presentinvention. The policy tree describes how the bandwidth available to thebandwidth allocation device is to be allocated among different classesof data streams. A tree structure is used to capture the hierarchicalnature of the allocation, however, any type of structure or relationalorganization can be used to describe the bandwidth allocations. Thetotal bandwidth available to the bandwidth allocation device is shown atthe root 602 position. The total bandwidth allocated to the root foreach device may be different based on network administrative decisionsor capacity limitations. The bandwidth available at the root 602 isallocated among a first generation of nodes (the nodes that connect tothe root), or classes, according to relative weights assigned to eachnode. For example, Customer 2, shown at 606, is allocated 30% of theroot bandwidth. The bandwidth allocated to each of the first generationnodes is further divided among nodes one generation below. In thismanner, the available network bandwidth represented at the root ishierarchically allocated to all the nodes, or classes, of the policytree.

In one embodiment, the policy tree 600 has the root 602 and Customer 1Customer 2 and Customer 3, shown at 604, 606 and 608 respectively,connected to the root 602. Customer 1 is allocated a maximum of 30% ofthe root bandwidth. Customer 2 and Customer 3 are also each allocated30% of the root bandwidth. The remaining 10% of the root bandwidth isallocated to all other users as shown at 610. The policy tree 600 isrepresentative of only one type of policy tree. Other types ofstructures or organizations may be used to define the bandwidthpolicies. Once the policies are defined, the system administrator hasdiscretion to change the allocations based on a variety of operatingparameters, such as the network's performance or changes in the priorityof the types of data streams.

Further refinement of the bandwidth policies are shown in the policytree 600. For example, Customer 2 and Customer 3 have their availablebandwidth further allocated to more specific types of data streams.Customer 2 has its 30% of the root bandwidth allocated so that 25% ofthe root is available for Movies 612 and 5% of the root is available forSports 614. Customer 3 has its 30% of the root bandwidth allocated sothat 20% of the root is available for News 616 and 10% of the root isavailable for Weather 618. In the device 500 of FIG. 5, the allocator512 receives allocations of the policy tree from the systemadministrator via the bandwidth policy input 508, and uses theallocations to negotiate transmission rates for the incoming datastreams with the active plug-ins.

FIG. 8 shows a table 700 representative of control information 506associated with the two data streams 502 and 504. The controlinformation 506 comprises stream annotations associated with each datastream. The stream annotations provide information about the datastreams that can be used to classify the data streams and to allocatebandwidth to each stream. The stream annotations can be divided into twocategories, namely, required annotations and general annotations. Therequired annotations are those annotations that must accompany everydata stream. The general annotations provide a way for a data stream tobe annotated with additional information that may be useful to end usersor when allocating bandwidth to the data stream.

In the embodiment of FIG. 8, exemplary stream annotations are shown forthe first data stream 502 and the second data stream 504. Threecategories of stream annotations are shown. The first category is astream identifier 702 which identifies each of the data streams. Byreceiving the stream identifier 702, end-users can identify incomingdata streams. Two other related categories, referred to as NameTAG 704and Value 706, form pairs that annotate each of the data streams. Forexample, the NameTAG “mediatype” 708 has a value of“Netshow” 710 for thedata stream 504. The NameTAG “mediatype” 708 has a value of “G2” 712 forthe data stream 504. The sender of the data stream annotates the datastream so that all receivers on the data network may identify the exactcontent of data stream. Some of the data stream annotations are requiredso that the data stream may be identified. Other annotations are generalannotations and are used by the sender to provide additional informationabout the data stream to end users. By using the policy tree and thestream annotations, database control structures can be formed from whichthe allocator 512 performs a variety of bandwidth allocation methodsthat result in effective utilization of the bandwidth available on thedata network.

FIG. 9 shows a portion of a policy tree wherein stream annotations areused to define bandwidth allocations. At node 750, 30% of the availableroot bandwidth is allocated to data streams having a Mediatype ofNetshow and a Rating of G. At node 752, 30% of the available rootbandwidth is allocated to data streams having a Mediatype of G2 and anAuthor of CBS Sports. All manner of bandwidth allocations can be made bydefining control structures that use the stream annotations to allocatebandwidth to selected types, or classes, of data streams.

Referring again to FIG. 6A, incorporated in the allocator 512 is abandwidth (BW) detector 524. The BW detector 524 can detect conditionswherein unallocated bandwidth exists. One such condition occurs whenbandwidth allocated to one or more policy classes, as defined by thepolicy tree, goes unutilized. For example, in the policy tree 700, if noWeather data stream is being received by the device 500, then thebandwidth allocated to this policy class at block 618 is unutilized.Another condition of unallocated bandwidth occurs when additionalbandwidth becomes available to the output of the media device 500 on thedata network, thereby increasing the bandwidth available at the rootposition 602. Unallocated bandwidth detected by the BW detector 524 canbe reallocated to currently existing data streams. The re-allocation ofunallocated bandwidth detected by the BW detector 524 is discussed morethoroughly with reference to FIG. 12.

In one aspect of the invention, a virtual overlay network may be formedfrom a plurality of bandwidth allocation devices like device 500. Thedetails of implementing an overlay network are describing in theco-pending application Ser. No. (09/323,869) and are beyond the scope ofthe present invention. With such an overlay architecture, the quality ofservice (QoS) delivered by the network can be carefully controlledthrough a combination of link provisioning in the underlying physicalnetwork and bandwidth provisioning across the virtual overlay networkusing the invention described herein. To provide QoS in apacket-switched network, approaches in the prior art universallyadvocate that all networking elements in a large, deployedinfrastructure be upgraded to support a variety of new switchingalgorithms, signaling protocols, packet strategies and so forth.However, in the present invention, QoS can be delivered without changesto the existing network elements and instead requires only the additionof the new routing elements at the overlay level. When and if nativenetworking elements become capable of delivering new forms of QoS, thenthe overlay abstraction can take advantage of those new devices locally.That is, the devices need not be deployed everywhere in the underlyingnetwork to aid in provision QoS. For example, data streams that areallocated to certain traffic classes within the present invention'sscope could be mapped onto native network-level classes in a fashionthat preserves the intended policy.

FIG. 10 shows a bandwidth allocation method 800 for use with thebandwidth allocation device 500 of the present invention. The method 800can be used to allocate bandwidth to data streams arriving at the device500. The method begins at block 802 wherein the system administratorestablishes a policy tree, for example, the policy tree 600, and inputsthe bandwidth allocations of the policy tree to the allocator 512.

At block 804 a new data stream and control information arrives at thedevice 500. The new data stream may comprise one data stream or maycomprise multiple data streams multiplexed together. Each data streamhas associated control information in the form of stream annotationssimilar to table 700.

At block 806 the stream annotation information is routed to theallocator 512 and the plug-in manager 514. At block 808, the plug-inmanager 512 activates a plug-in for each arriving data stream. The typeof plug-in activated is determined from the type of data streamarriving, indicated by the stream annotations in the controlinformation. For example, if the control information has streamannotations that the arriving data stream contains a certain type ofvideo data, the plug-in manager 514 activates a plug-in capable ofhandling that type of video data. If a data stream is a multiplexedstream containing more than one data stream, then the plug-in manager514 activates a plug-in for each individual data stream of themultiplexed stream.

At block 810, the newly created plug-in determines one or more ratesavailable to transmit, or forward, the data stream on the data network.For example, some data streams have only one forwarding rate, whileother data streams have several forwarding rates. Different rates mayresult in differences in stream quality, for instance, forwarding avideo stream in color versus black and white.

At block 812, the allocator 512 negotiates with each plug-in aforwarding rate for their respective data streams. In some case, as innon real-time data streams, there will exist many possible forwardingrates. In other cases, as in real-time data streams, only a few possibleforwarding rates will exist that allow the data stream to be transmittedwithout serious degradation. Based on the policy tree and the availabletransmission rates indicated by the plug-in, the allocator 512 willnegotiate a forwarding rate for the data stream that will be within thepolicy tree allocations. For example, the policy tree 600 allocates 5%of the available bandwidth to Sports 614. Assuming the bandwidthallocated to all other classes of the policy tree is fully utilized, ifa sports data stream is received, the data rate will be limited to 5% ofthe available bandwidth. If the plug-in associated with the sports datastream indicates that a forwarding rate is possible which uses no morethan 5% of the available bandwidth, then the allocator 512 will be ableto allocate the bandwidth to forward the sports data stream on thenetwork. If it turns out that the plug-in indicates that the slowestpossible forwarding rate will require 7% of the available bandwidth, theallocator 512 will be unable to meet this requirement and the sport datastream will not be forwarded on the network.

At block 814 the plug-in and the allocator 512 have negotiated aforwarding rate for the data stream that is within the policy treeallocations. The plug-in begins transforming the received data streaminto a transformed data stream having the negotiated data rate. Toaccomplish this, the plug-in may have to perform such operations aslayer dropping or transcoding to adjust the incoming data stream tomatch the negotiated rate.

At block 816 the transformed data stream is-sent to the output link 522where all the transformed data streams are combined to form an outputdata stream. The output data stream contains all the input data streamstransformed to utilize the available network bandwidth to conform to thepolicy tree. At block 818, transmission of the output data stream on thedata network occurs.

FIG. 11 shows another method 900 for use with the embodiment 500 of thepresent invention. Method 900 demonstrates how the allocator 512 adaptsto changing conditions of an existing data stream to dynamicallyre-allocate the bandwidth of the data network.

At block 902, a plug-in is currently forwarding a received data streamon the network using a, previously negotiated for, allocated portion ofthe available bandwidth. At block 904, a change occurs to the datastream affecting the bandwidth requirements for the data stream. Forexample,. the minimum allowable forwarding rate for the data stream maybe increased. The stream annotations associated with the data streamreflect the change.

At block 906, the plug-in determines the new forwarding rates availablefor the received data stream and informs the allocator 512 of the newrates. At block 908, the allocator determines if the stream can beforwarded at the existing rate or if a new rate should be negotiated. Ifa new rate is required, the plug-in and the allocator 512 renegotiate anew rate for the data stream taking into account the new set ofavailable rates. A new forwarding rate for the data stream will benegotiated, as long as the new rate does not exceed the allocationsdefined by the policy tree for the class represented by the data stream.

At block 910, the plug-in begins transforming the data stream to thenewly negotiated rate. At block 912, the newly transformed data streamis sent to the output link 522 and at block 914 the transformed datastream is transmitted on the data network. Thus, using the device 500 ofthe present invention, it is possible to dynamically allocate thebandwidth of the data network to accommodate changing forwarding raterequirements of an existing data stream.

FIG. 12 shows another method 1000 for use with the device 500 of thepresent invention. Method 1000 demonstrates how the allocator 512 adaptsto changing network conditions to dynamically allocate the bandwidth ofthe data network to avoid unallocated bandwidth conditions. Unallocatedbandwidth conditions exist when the bandwidth allocations of the policytree are not fully utilized. For example, referring to the policy tree600 of FIG. 7, the bandwidth allocation for Customer 3 is 30%, whereinthe News 616 allocation is 20% and the Weather 618 allocation is 10%. Ifno Weather data stream exists, the 10% allocation will be unused,thereby creating an unallocated bandwidth condition. To avoid this, theallocator 512 reallocates the unallocated bandwidth to other datastreams. The method 1000 demonstrates how the allocator dynamicallyre-allocates available bandwidth when data streams begin, end or when adata stream otherwise changes its bandwidth requirements.

At block 1002, an initial condition exists wherein received data streamsfully utilize the available network bandwidth according to theallocations of the policy tree 600. At block 1004, a data streamterminates, for example, the Weather 618 stream terminates leaving 10%of the available bandwidth unallocated. At block 1006, the allocator 512attempts to dynamically reallocate the unused bandwidth. The allocator512 knows the available rates for all active plug-ins as a result of theinitial negotiation processes. The allocator 512 attempts to determine aplug-in that can use a higher forwarding rate without exceeding theavailable bandwidth. The allocator 512 first looks to allocate theunallocated bandwidth to data streams that are siblings to theterminated data stream. In this situation, the News 616 data stream is asibling data stream. If the allocator can allocate all the unallocatedbandwidth to the sibling data stream, then the method proceeds to block1012, otherwise the method proceeds to block 1008.

At block 1008, the allocator 512 was unable to allocate all of theunallocated bandwidth to a sibling class, so the allocator looks toallocate the unallocated bandwidth to parent class according to thepolicy tree 600. For example, Customer 2 is a parent class to theWeather data stream.

At block 1010, if the allocator 512 fails to find a sibling or parent toallocate the unallocated bandwidth to, the unallocated bandwidth willremain unused and the network will be underutilized.

At block 1012, the allocator 512 has found one or more data streams,associated with a sibling and/or parent class, that can use theunallocated bandwidth. Since the allocator knows the availabletransmission rates for all the data streams, the allocator sends aninstruction to the respective plug-ins to use new transmission rates toforward their data streams. The new forwarding rates are selected fromthe available rates known to exist for each data stream. If a datastream is instructed to use a higher forwarding rate, it may exceed itsrespective bandwidth allocation defined by the policy tree. However,this condition is desirable to allocate unallocated bandwidth andimprove network utilization.

At block 1014, the plug-in responds to the instructions from theallocator 512 by transforming the data stream to the new forwardingrate. At block 1016, the transformed data streams are sent to the outputlink 522 and at block 1018 the output link transmits the data streams onthe data network. As a result of the re-allocation process, theunallocated bandwidth of the data network is eliminated or reduced andthe network operates more efficiently.

It will be obvious to one with skill in the art that the unallocatedbandwidth may be re-allocated to more than one plug-in and that theresulting bandwidth allocations may be different from the allocationsdefined by the policy tree 600. As more data streams arrive orterminate, or as existing data streams change their requirements, thebandwidth may be re-allocated again. Thus, the method 1000 furtherdemonstrates how changing network conditions trigger another bandwidthre-allocation to conform to the policy tree and thereby keep thebandwidth efficiently utilized.

At block 1020, after the unallocated bandwidth has been allocated toexisting data streams, a new incoming data stream arrives at device 500.The new incoming data stream contains control information that isreceived by the allocator 512 and the plug-in manager 514. At block1022, the plug-in manager 514 creates a plug-in to handle the new datastream. At block 1024, the plug-in determines from the streamannotations what forwarding rates are available and provides these ratesto the allocator 512.

At block 1026, the allocator determines how to recapture some or all ofthe bandwidth that was previously unallocated, so that the new datastream can be allocated bandwidth in conformance with the policy tree.For example, the policy tree 600 specifies 10% of the bandwidth forWeather 618 data. If a new Weather data stream arrives, the previouslyunallocated bandwidth will be reacquired so that the new Weather datacan be allocated 10% in accordance with the policy tree 600.

At block 1028, the allocator 512 requests new forwarding rates for allplug-ins that are affected by the re-allocation. The new forwardingrates are selected from the known forwarding rates previously determinedby each plug-in. At block 1030, the affected plug-ins transform theirrespective data streams to the requested forwarding rates. At block 1032the data streams, including the new data stream, are sent to the outputlink 522 for output on the data network at the requested rates. At block1034, as a result of the reallocation, the recovered bandwidth providesthe new data stream its portion of the available network bandwidth asdefined by the policy tree.

Although the dynamic bandwidth re-allocation helps to increase theefficiency of the network, excessive re-allocation can be detrimental.For example, a streaming video player can only take advantage ofincreased bandwidth by switching layers, an event that can require aseveral second interruption in viewing. To make it worthwhile to disrupta viewing session to switch layers, the video player needs an explicitindication that there is enough unallocated bandwidth for a layer changeand that the unallocated bandwidth will be available for awhile.Therefore, bandwidth reallocations to a few plug-ins should not triggerchanges to every plug-in, and bandwidth reallocations should not occurtoo often.

FIG. 13 shows a method 1100 for use with the device 500 of the presentinvention. The method 1100 provides a way to schedule bandwidthreallocations so that the reallocations are not done too frequently. Themethod 1100 also prevents a noisy plug-in from disrupting thereallocation process. A noisy plug-in is a plug-in that repeatedlyrequests forwarding rate changes.

At block 1102, a reallocation of the network bandwidth occurs. Thereallocation may be due to various reasons, such as to correct anunallocated bandwidth condition or to accommodate a new data stream. Atblock 1104, a reallocation timer resets and begins timing the intervalbetween reallocations. At block 1106, a plug-in request timer resets andbegins timing the interval between plug-in requests. The plug-in requestcan be a request to begin or end a data stream, or to change theforwarding rate of an existing data stream. At block 1108, a checkoccurs for new plug-in requests. If there are new plug-in requests, theallocator 512 handles the request and the method 1100 proceeds to block1106 where the request timer is reset.

At block 1110, a check occurs to determine if the request timer hastimed out. The timeout occurs if no new plug-in requests are receivedfor a selected time duration. The selected time duration is determinedby the system administrator. If the request timer has not timed out thenthe method 1100 proceeds to block 1112. If the request timer has timedout then the method 1100 proceeds to block 1114.

At block 1114, the allocator performs a reallocation of the availablenetwork bandwidth. After the reallocation, the method 1100 proceeds toblock 1104 where the allocation timer is reset. At block 1112 a checkoccurs to see if the allocation timer has timed out. The allocationtimer indicates the duration between allocations. The timeout durationis determined by the system administrator. If the allocation timer hasnot timed out then the method 1100 continues at block 1108 by checkingfor new plug-in requests. If the allocation timer has timed out, themethod proceeds to block 1114 where the allocator 512 performs areallocation. At the end of the reallocation at block 1114, the method1100 proceeds to block 1104 where the reallocation timer is reset.

The allocator uses selectable time intervals for the plug-in requesttimer and the reallocation timer to adjust how often the availablebandwidth of the data network is reallocated. By using the requesttimer, the allocator ensures that the network data streams are stablebefore beginning a reallocation process. By using the reallocationtimer, the allocator can force a reallocation regardless of the state ofthe data streams, so that a noisy plug-in can't disrupt the bandwidthreallocation process by preventing timeout of the plug-in request timer.

As will be apparent to those of skill in the art, variations in theabove described apparatus methods for allocating the bandwidth of thedata network are possible without deviating from the scope of thepresent invention. Embodiments of the present are suitable for use inall network environments wherein efficient allocation of networkbandwidth is desired. Accordingly, the disclosures and descriptionsherein are intended to be illustrative, but not limiting, of the scopeof the invention which is set forth in the following claims.

1. A method for allocating bandwidth of a data network to a plurality ofdata streams, comprising: specifying apportionment of the bandwidth to aplurality of data classes; receiving a plurality of data streams whereineach data stream has at least one attribute that associates the datastream with one of the data classes; from a plurality of acceptabletransfer rates, negotiating a transfer rate for each data stream,wherein the transfer rate is limited to the bandwidth apportioned to thedata class associated with each data stream; and transmitting the datastreams on the data network at the negotiated transfer rates a streamprocessor, having logic to receive the data stream and to; an outputcoupled to the stream processor, having logic to receive the data streamand transmit the data stream on the data network at the negotiatedtransfer rate.
 2. The method of claim 1 wherein the step of receivingcomprises steps of: receiving stream annotations associated with each ofthe data streams; and activating a plug-in to receive each data stream,wherein the type of plug-in is determined from the stream annotations.3. The method of claim 1 wherein the step of negotiating comprises stepsof: determining a plurality of acceptable transmission rates for eachdata stream; and negotiating a transfer rate for each data stream,wherein the transfer rate is a selected one of the acceptabletransmission rates and is limited to the bandwidth apportioned to thedata class associated with each data stream.
 4. The method of claim 1wherein the step of transmitting comprises steps of: transforming eachdata stream to the negotiated transfer rate; and transmitting the datastreams on the data network at the negotiated transfer rates.
 5. Themethod of claim 4 wherein the step of transforming comprises a step ofthinning, transcoding or decimating the data stream to the negotiatedtransfer rate.
 6. The method of claim 1 wherein the transfer rate is afirst transfer rate and the method further comprises steps of:determining unallocated bandwidth on the data network; negotiating asecond transfer rate for at least one data stream, wherein the secondtransfer rate uses the unallocated bandwidth; transforming the at leastone data stream to the negotiated second transfer rate; and transmittingthe at least one data stream on the data network at the second transferrate.
 7. The method of claim 6 further comprises steps of: receiving atleast a second data stream having an associated data class; negotiatinga third transfer rate for the at least one data stream, wherein thethird transfer rate is limited to the bandwidth apportioned to the dataclass associated with the at least one data stream; negotiating a fourthtransfer rate for the at least second data stream, wherein the fourthtransfer rate is limited to the bandwidth apportioned to the data classassociated with the at least second data stream; and transmitting on thedata network, the at least one data stream at the third transfer rateand the at least a second data stream at the fourth data rate. 8-20.(cancelled)
 21. In a data network configured to transmit data streams atnegotiated transfer rates, wherein each of a plurality of data streamshas at least one attribute that associates the data stream with aparticular data class, and wherein a negotiated transfer rate is limitedto bandwidth apportioned to the data class of a data stream, theimprovement comprising: allocating bandwidth to the data streams bynegotiating a transfer rate for each of the plurality of data streamsfrom a plurality of acceptable transfer rates prior to transmitting eachdata stream at the negotiated transfer rate.
 22. A system for allocatingbandwidth of a data network to a plurality of data streams, comprising:means for determine a plurality of acceptable transmission rates for adata stream; means for negotiating a transfer rate for the data stream,wherein the transfer rate is a selected one of the plurality ofacceptable transmission rates and is limited to a portion of thebandwidth apportioned to a data class associated the data stream; andmeans for transmitting the data stream on the data network at thenegotiated transfer rate.